home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Collections: MegaDisc
/
MegaDisc 27 (1992-03)(MegaDisc Digital Publishing)(AU)(Disk 1 of 2)[WB].zip
/
MegaDisc 27 (1992-03)(MegaDisc Digital Publishing)(AU)(Disk 1 of 2)[WB].adf
/
Tutes_&_CLI
/
ProForma_Score
/
ProForma_Score
Wrap
Text File
|
1992-03-30
|
16KB
|
373 lines
00000
00000
00000
00000
00000
0
0
0
0
0
0
0
00000
0
0
0
0000
000
0
0
0
0
0
0
0
00000
00000
00000
0
0
00000
How a simple command in an Authoring
Language took on a large number of tasks
by John Collett
Ed: This is not an Amiga-specific article, but does address a subject of
interest to anyone who's into programming or authoring languages, etc. by
John, who has contributed so much good material to Megadisc in the past -
see also his Amos tutorial this issue, amongst other things.
(( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 ))
When, years ago, the authoring language Proforma was taking shape, I
included in it a method of displaying to students their score to date
in the current study unit. I didn't know whether its function would
be merely informative, or whether it might play a role in student
motivation, since students appear to attach a curious degree of
importance to scores, marks, grades, and credits. I normally use it
at the end of each major section of a unit. It screens a message
such as "Your score to date is 15 out of 20, or 75%". It simply
means having the program keep a tally of attempted and correctly
answered questions, and using the "<SCORE" command in a unit script
when the display is required. At certain points within a unit and/or
at the end of a unit, students can be advised, according to their
score, to move on to the next unit, to repeat the whole or a part of
the current unit, to redo one or more earlier units in the series, or
to undertake study from some other source.
Command Lines and Arguments
The language was designed to be easy to use, but flexible enough to
meet most needs of teachers and lecturers who wish to prepare
tutorial-style study units. Its command mechanism is that any line in
a tutorial script beginning with < is interpreted as a command
line. The following characters on that line are a command or any
abbreviation thereof, as long as enough characters are given to make
the abbreviation unique. For example, while <B or <b is enough to
invoke the <BOX command, <SCORE needs at least <SC or <sc to
distinguish it from <SUBTITLE.
Many of the commands carry additional arguments to convey details of
a user's requirements to the program, and these arguments are
separated from the command word by a space, and from each other, if
there are more than one, by commas. For example, methods of
highlighting text include reverse video (the default), bolding,
and underlining. Highlighting can be invoked for one (the default)
or more lines, and within the actual lines of script the piece of
text to be highlighted is enclosed {thus}. So if the < is the
initial character on its line, then
<Highlight B,3
invokes bolding of marked text in the next three lines.
This:
<Highlight U,2
and this:
This line {and} the next will
contain {underlined} words.
will produce
This line
and
the next will
contain
underlined
words.
A function to extract either an integer or a string from a given
position in a set of arguments obviously plays a central role in the
processing of a command line, but in its earliest simple form the
<SCORE command carried no arguments.
Additions to the <SCORE command
Study units are normally constructed in a linear fashion - students
start at the beginning, and work through to the end. They can also
skip forwards or loop back, making it possible, for example, to go
back over a section which may not have been thoroughly understood,
or, on a second use of a particular unit, for revision purposes, to
jump directly to problem areas.
It also means that in a unit which contains, say, 20 questions, a
student may attempt fewer than 20, by jumping past some of them, or
more than 20, by looping back and repeating some. Combining accuracy
with fairness when displaying scores and in record keeping is quite a
problem, the intricacies of which need not concern us here. It is
clear, however, that the program needs to know how many questions
there are in a unit before any score calculations can be undertaken.
The easiest way to give it that information is simply to tell it, and
this was the first additional function of the <SCORE command. (Yes,
the program could be made to scan through a unit and simply count
the questions, but that seemed unnecessary.)
If one argument is added to <SCORE, and if that argument is a number,
then its function is to tell the program how many questions there are
in a unit. The best place for it is at the beginning of a script,
within the first screen load, so that it cannot be skipped over, and
will always be processed. It has no immediate effect on what is seen
on the screen. But students embarking on a unit might like to know
how many questions lie ahead of them. While the command <SCORE 20
tells the program that there are 20 questions, <SCORE "20" (note the
quotation marks) does the same, and also displays this message on the
screen:
There are 20 questions in this unit.
Tutorial Core Elements
A straight count of questions and correct answers proved to be
insufficiently flexible for some aspects of diagnosis and advice.
Study units are not usually just a straight and even development from
beginning to end. They have a structure, with major and minor roles
being played by various parts, and often, via explanation, example
and practice, they work their way towards one or more particular
targets. Out of, say, 20 questions, the first 16 may be a part of
the teaching process leading up to the final four, and it is a
student's performance on that four which indicates whether or not
certain fundamental concepts have been grasped and are able to be
applied. We may well be more interested in the score obtained on
the last four questions than in the total score, and would like to
base diagnosis and advice on that part of the student's performance.
The concept of a part-score took shape, and the <SCORE command took
on three more tasks.
<SCORE BEGIN (or any abbreviations) marks the beginning of a section
in which local score-keeping will be applied.
<SCORE END marks the end of such a section.
Neither of them have any visible output.
<SCORE SUBSET displays the score to date on a current sub-section.
Using these, a sequence of commands in a study text (and their screen
output, if any) might go thus:
<SCORE
Your total score to date is 12 out of 16, or 75%
<SCORE B
(Special section of tutorial text, including, say, four questions.)
<SCORE S
Your score on the last 4 questions was 2, or 50%
<SCORE E
<SCORE
Your total score to date is 14 out of 20, or 70%
Specific advice can be given on the basis of part-scores:
If your score on that section was 50% or less, go back to
page 8 and work through from there again.
There may even be just one key question in the marked section,
producing a score of 0% or 100%, and advice might be something like:
If you did not answer that question correctly, you are advised to
leave this unit now, revise units 3 and 4, and then try this unit
again.
Remedial and Extension Materials
Giving advice is one thing, but having students act on it is another,
and a further addition to the language was the command <EXTRA. Full
details are not given here - just enough to indicate its main
function, and how it can be combined with the idea of a scored
sub-section to produce a very flexible teaching tool. The command
<EXTRA works like this:
<EXTRA >80
Only students scoring above 80% at this point will see the next
section of the unit, as far as an end marker <EXTRA 0. It will be
extension/enrichment material which students with lower scores might
find too challenging.
<EXTRA <40
Similar, but for students scoring
below
40%. What they see will
be remedial/revision material.
Either of these can take a second argument:
<EXTRA <n,SUBSET
or
<EXTRA >n,SUBSET
in which case the provision of extension or remedial work is based on
performance on a particular section of a study script as defined by a
preceding <SCORE BEGIN. With a little imagination and not a little
work, the use of <EXTRA, <SCORE BEGIN and <SCORE END commands can
convert what what starts off as a linear tutorial into a complex
branching structure, responding sensitively to the needs of
individual students. Nor need students know, unless text is
specifically included to inform them of the fact, that they have
been re-routed along a brief remedial or extension side-track.
Examples of applications
1 Remedial work after any question
The language already allows for a study text to contain comments on
each question, comments which appear only if a question is answered
wrongly. But any question can be enclosed in a sub-section
containing just that one question. Then if the score on the question
is less than 100% (i.e. it was answered wrongly), a remedial <EXTRA
track can be pursued, containing as much in the way of further
explanations and practice questions as seems appropriate.
<SCORE BEGIN
Beginning of sub-section. Script contains a target question.
<EXTRA <100,SUBSET
Remedial work for students who answer the one question wrongly.
This can be any length, and can contain more questions if
required.
<EXTRA 0
End of remedial patch.
<SCORE END
End of sub-section
2 Early exclusion of non-starters
After a few questions, very low scorers can be advised to quit, and
to do other preliminary work before returning to the current unit.
With <EXTRA, they can be more than advised - they can be taken to the
very end of the unit and dropped off, returning them to the menu from
which they made their original choice.
I don't make use of this in my own units, but it would be a way of
dealing with those students who go through a unit once, just entering
garbage as answers, copy down the required answers, and then go
through again, copying the required answers in, scoring highly, but
learning virtually nothing. I could arrange for anyone scoring less
than, say, 30% after the first few questions to be unceremoniously
ejected from a unit. It would be interesting, to say the least, to
see what reaction this would produce through our "Message" program.
Menu Listing of Student Scores to Date
A completely different use of the <SCORE command occurs in our menu
units, in which, by definition, the only question asked is "Which
unit do you want?"
The task of the <SCORE command here is to open the relevant random-
access file, obtain the record relating to the student using the
program, and display scores obtained on all units to date. More than
that, it displays in bolded form those units of which the date
deadline has been passed. The implied message is "You should have
made your first serious attempt at these units by now." We are still
exploring different types of penalties for lateness, and still
assessing their effectiveness as a way of getting students to do
their computer work regularly, and at times designed to tie in with
what is being done in class.
For some time the penalty has taken this form:
Unless you have made at least one serious attempt at this unit
(scoring over 50%) by the deadline, your score will not be recorded.
Scores over 50% by the deadline can be increased, and will never
be reduced.
This presented at least two problems:
1
Some students who had missed a deadline did not even bother to make
late use of a unit, knowing that whatever mark they obtained, it
would not be recorded.
2
Towards the end of the year, students tried to squeeze any extra
marks they could out of the units, in order to improve their final
mean score. Queues developed, and the system was put under pressure.
The whole thing became nonsensical, with hours being spent to obtain
a 0.01% improvement in a recorded mean score, without much real
learning necessarily taking place.
A variation being tried in 1992 takes this form:
Any score obtained before the deadline will be recorded. Scores
obtained after the deadline will be reduced by 1% per day by which
the deadline has been passed, but existing marks will never be
reduced.
This will penalize less severely attempts which are slightly late, so
that they are still worth making. It should encourage students to
space their best attempts more regularly throughout the year, and
reduce the end-of-year striving for marks for their own sake.
We'll observe student reaction to and comments on this new regime.
The display of scores-to-date is invoked by the score command with
five arguments: first, last, column, row, spacing. Thus:
<SCORE 1,5,30,4,2
would display scores for units 1 to 5 inclusive, with the column
starting at x and y values of 30 and 4. The entries would appear on
alternate lines (the "2" of the fifth argument).
Displaying Overall Mean Score to Date
Many of our other programs display not only scores-to-date on
attempted units, but also the mean score. This has been the latest
(last?) addition to the list of tasks carried out by the <SCORE
command. It produces this sort of thing:
-------
| Mean |
| score |
| 75.6% |
-------
The only arguments it needs are x and y values to tell it where to
display that score and, as with all <SCORE commands, it is by the
number and nature of the attached arguments that the program knows
which particular procedure is required.
A Summary of Currently Available Score Commands
In a study script:
<SCORE - Displays the total score to date.
<SCORE 30 - Tells program the number of questions in unit.
<SCORE "30" - Ditto, and also tells the students.
<SCORE BEGIN - Marks start of subset
<SCORE SUBSET - Displays subset score
<SCORE END - Marks end of subset
In a menu script:
<SCORE 1,10,26,5,1 - Displays previously obtained scores
on a set of units.
<SCORE 70,15 - Locates the display of the mean score
on units attempted to date.
Hamilton,N.Z.,March 1992
(( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 ))
